如何将 Spring Boot 微服务部署到容器平台上？ | 最佳实践
相关场景如下：
Spring Cloud 微服务系统已经提前搞好了，并没有运行在容器平台上，而是直接运行在虚机上。这次就是结合Spring Boot的组件和K8S (OpenShift)的相关概念和优势 ，将其迁移部署到容器平台上。
Spring Boot 全家桶及替代品
备注：替代品请关注K8S的相关替代品，本次主要目的是结合Spring Boot的组件和OpenShift的相关概念和优势。
框架
虽然调用微服务通常是通过HTTP发送JSON或XML payload这样简单的事情，但是各种各样的考虑导致了专用客户端库的流行，特别是在Spring Boot环境中。这些库不仅提供与Spring Boot的集成，还提供与微服务体系结构中经常需要的许多其他工具和库的集成。
Ribbon
Ribbon 是一个具有内置客户端负载均衡的进程间通信(RPC)库。主要的使用模型包括REST调用和各种序列化方案支持。
这次的实例程序只使用Ribbon的最基本功能。因为Ribbon 就是Spring Boot框架全家桶的一员.
服务注册
微服务体系架构通常意味着在私有、混合或公共云中对单个服务进行动态扩展，其中主机的数量和地址不能总是预先预测或静态配置。(说人话, 微服务经常会横向动态扩展.) 解决方案是使用服务注册中心作为发现每个服务的已部署实例的起点。这通常由客户端库或负载均衡层进行匹配，当发现实例不再存在时，该层会无缝地进行故障转移，并更新服务注册表查找的缓存。更进一步说，客户机库和服务注册中心之间的集成可以使查找和调用过程成为单个步骤，并且对开发人员是透明的。
在现代云环境中，这种功能通常由平台提供（说人话: 这个应该由我K8S来做! 你框架做的太多了
这次的示例构建在OpenShift之上，就用K8S的Service来做服务注册。
Eureka
Eureka是一种基于REST(REpresentational State Transfer)的服务，主要用于微服务中定位服务，以实现中间层服务器的负载平衡和故障转移。
Ribbon和Eureka之间的紧密集成允许在调用者使用Ribbon库时声明性地使用Eureka.
负载均衡
对于客户端对无状态服务的调用，高可用性(HA)意味着需要从服务注册中心查找服务，以及可用实例之间的负载平衡。前面提到的客户端库包括合并这两个步骤的功能，但是容器平台通过在 Service 抽象概念中包含负载平衡功能，使得这两个操作变得多余。OpenShift提供一个单一地址，在这个地址中，调用将被负载平衡并重定向到适当的实例。(说人话: Spring Boot虽然提供了库, 但还是要写代码的; 容器平台直接提供Service, Service自动在实例间负载均衡. 对于开发来说, 就是只用配一个Service地址, 就可以负载均衡).
Ribbon
Ribbon 允许在声明的静态实例列表之间进行负载均衡，或者在注册表查找中发现服务的任意多个实例之间进行负载均衡。
断路器
微服务的高度分布式特性意味着远程调用失败的风险更高，因为此类远程调用的数量增加了。断路器模式可以通过隔离有问题的服务和避免破坏性超时来帮助避免这类故障的级联。
Hystrix
Hystrix是一个延迟处理和故障转移功能库，旨在隔离远程系统、服务和第三方库的访问点，中止级联故障，并在不可避免的复杂分布式系统中启用弹性。
Hystrix实现了断路器和 bulkhead 模式。
外部化配置
外部化配置管理解决方案可以为配置文件、命令行参数和环境变量的典型组合提供一种优雅的替代方案，这些配置文件、命令行参数和环境变量用于使应用程序更加可移植，并减少对外部更改的响应。
Spring Cloud Config
Spring Cloud Config为分布式系统中的外部化配置提供了服务器和客户端支持。有了Config Server，您就有了一个中心位置来管理跨所有环境的应用程序的外部属性。
分布式 Tracing
尽管微服务体系结构有很多优点，但是很难分析和排除故障。每个业务请求在不同的层上生成对各个服务的多个调用，以及在各个服务之间的多个调用。分布式 Tracing 将所有单独的服务调用绑定在一起，并通过惟一生成的ID将它们与业务请求关联起来。
Sleuth/Zipkin
Spring Cloud Sleuth为应用程序中请求点上的每个调用和 span ID生成trace ID。这些信息可以与日志框架集成，通过跟踪日志文件来帮助解决应用程序的故障，或者广播到Zipkin服务器并存储分析和报告。
代理/路由
在每个服务调用之前添加代理，可以在调用之前和之后应用各种 filters，以及微服务体系结构中的许多常见模式，比如A/B测试。静态和动态路由规则可以帮助选择所需的服务版本。
Zuul
Zuul是一种边缘服务，提供动态路由、监视、弹性、安全性等。
Zuul支持多种路由模型：
映射到目的地的声明式URL模式，
驻留在应用程序 archive之外并动态确定路由的groovy脚本
小结
话不多说, 看表：
Demo 架构
这个Demo 架构演示了在微服务体系结构风格中构建的机票搜索系统 。每个单独的微服务都是作为REST服务实现的，它位于Spring Boot之上，带有一个嵌入式Tomcat服务器，部署在OpenShift镜像上，并支持OpenJDK。典型微服务的软件栈如下:
每个微服务实例在一个容器实例中运行，每个OpenShift pod有一个容器，每个Service 有一个容器。在其核心，用微服务体系结构风格构建的应用程序由许多相互调用的复制容器组成.
应用程序的核心功能是由微服务提供的，每个微服务承担一个单一的职责。有一个服务充当 API网关 ，调用单个微服务并聚合响应，以便更容易地使用它。
该架构还实现并扩展了Spring Sleuth和OpenZipkin的分布式跟踪(distributed tracing)功能。OpenZipkin作为一个单独的服务运行，使用一个MySQL数据库来持久化它的数据，应用程序中的每个服务都会调用Zipkin。
最后，Demo 应用使用 Zuul 作为边缘服务来提供静态和动态路由。结果是，所有服务调用实际上都被定向到Zuul，并由它适当地代理请求。这个Demo也会演示 A/B测试 , 通过提供销售服务的另一个版本并在运行时决定将其用于哪一类客户。
小结
应用架构 :
用户通过前端程序(presentation的页面进行访问, 访问的请求会调用API Gateway, 通过Zuul 作为代理路由到各个微服务: Flights, Airports, Sales. 同时请求的tracing信息会发送给zipkin.
用到的组件 :
结合前文来看，具体如下：
原题：本文包括《Spring Boot 微服务上容器平台的最佳实践 - 1》《Spring Boot 微服务上容器平台的最佳实践 - 2》 点击文末阅读原文，可到社区原文下提问交流 觉得本文有用，请转发或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区以下 技术主题 ，将会不断更新优质资料、文章。地址：
微服务：http://www.talkwithtrend.com/Topic/95163
容器云：http://www.talkwithtrend.com/Topic/98447
下载 twt 社区客户端 APP
长按识别二维码即可下载
或到应用商店搜索“twt”
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场